Многие крупные организации до сих пор используют платформу VMware vSphere 6.0 в качестве основы своей ИТ-инфраструктуры. Это обусловлено трудностями планирования апгрейда для большого парка серверов, лицензионной спецификой и в целом нежеланием трогать то, что работает хорошо.

Но надо обязательно напомнить, что 12 марта 2020 года, согласно плану, указанному в документе VMware Lifecycle Product Matrix, платформе vSphere 6.0 и гипервизору ESXi 6.0 наступает End of Life (EoL), а в терминологии VMware - End of General Support:

Согласно политикам VMware Support Policies, статус End of General Support для продуктов VMware означает, что для них перестают выпускаться существенные обновления и патчи. Поддержка по телефону также заканчивается, а с точки зрения апдейтов выпускаются только самые критичные обновления, закрывающие дырки безопасности и самые серьезные баги. То есть продукт входит в фазу Technical Guidance:

В связи с этим, пользователям vSphere 6.0 настоятельно рекомендуется провести обновление до версий vSphere 6.5 или 6.7 к этому времени. Кстати, надо отметить, что у обеих версий дата перехода в фазу Technical Guidance одна и та же - 15 ноября 2021 года:

Совместимость вашей платформы VMware vSphere 6.0, а точнее ее компонентов ESXi 6.0 и vCenter 6.0, с другими продуктами VMware вы можете проверить на специальной странице VMware Product Interoperability Matrices:

Не все администраторы виртуальной инфраструктуры VMware vSphere в курсе, что в этой платформе доступен удобный инструмент, который позволяет сгенерировать PowerCLI-сценарий из последовательности действий, которые выполняет администратор в интерфейсе vSphere Client.

Эта функция называется Code Capture, и появилась она весной прошлого года в обновлении платформы VMware vSphere 6.7 Update 2, о которой мы писали вот тут. Этот механизм VMware тестировала еще в далеком 2009 году, тогда он назывался Project Onyx.

Чтобы получить доступ к этой фиче, нужно в меню vSphere Client выбрать пункт Developer Center, где есть переключатель Enable Code Capture:

После того, как вы включите Code Capture, в верхнем тулбаре клиента появится красная кнопка записи:

Например, можно нажать на нее и, как показано на скриншоте выше, запустить клонирование виртуальной машины, а затем включить созданную ВМ.

После того, как вы запишете сессию, можно нажать кнопку Stop Recording, после чего будет сгенерирован PowerCLI-сценарий, с помощью которого можно автоматизировать развертывание новой машины:

Полученный скрипт можно скопировать или скачать для последующего его изменения уже в собственном редакторе. Надо отметить, что поскольку сценарий генерируется автоматически - он получается далеко не самым оптимальным с точки зрения структуры и времени работы. Поэтому если вы умеете разрабатывать сценарии на PowerCLI, то лучше делать их вручную с нуля. С другой стороны, не все действия в клиенте понятно, как автоматизировать, и какие командлеты использовать - поэтому Code Capture определенно может помочь подобрать нужные.

Если хочется сделать сценарий по-новой, то можно нажать кнопку "Clear and start another" - это удалит прошлый скрипт (не забудьте сохранить его, если он нужен) и начнет новую сессию записи.

Чтобы отключить функцию code capture для всех пользователей, нужно добавить строчку "codecapture.disabled=true" в файл конфигурации клиента vSphere Client (надо будет его перезапустить): /etc/vmware/vsphere-client/vsphere-client/webclient.properties.

Интересный баг обнаружил Matt для своей виртуальной инфраструктуры, когда пытался клонировать виртуальные машины с выставленной опцией "customize this virtual machine’s hardware":

Оказалось, что после создания клона его VMDK-диск указывал на VMDK клонируемой машины, что, само собой, является серьезнейшим багом. После работы с техподдержкой оказалось, что баг не такой и частый, так как проявляется только когда в VMX-файле исходной машины параметр disk.enableuuid выставлен в значение TRUE (по умолчанию он отсутствует и применяется как FALSE).

Данный параметр иногда добавляется пользователями в соответствии с рекомендациями вендоров решений для резервного копирования и управления виртуальной средой - он позволяет убедиться в том, что VMDK диск предоставляет машине консистентный UUID для корректного монтирования.

Workaround для этого бага - это либо использовать для операций клонирования старый vSphere Web Client, либо делать это через PowerCLI. Можно также не использовать опцию "customize this virtual machine’s hardware", а настроить железо ВМ после выполнения клонирования. Также баг не проявляется если делать клонирование выключенной машины.

В блоге о производительности VMware появился интересный пост о том, как технология CPU Hot Add влияет на производительность операций в виртуальной машине. Как вы знаете, возможности Hot Add в VMware vSphere позволяют добавлять аппаратное обеспечение в виртуальную машину без необходимости ее выключения. В частности, CPU Hot Add позволяет добавить vCPU в запущенную ВМ таким образом, чтобы поддерживающая эту возможность гостевая ОС сразу приняла этот процессор в работу.

Между тем, согласно статье KB 2040375, функция Hot Add существенно влияет на производительность гостевой ОС, поскольку механизм горячего добавления узлов отключает функцию vNUMA. Напомним, что этот механизм включается при количестве vCPU большем 8 для одной виртуальной машины и позволяет самым оптимальным образом отображать физическую архитектуру сервера на топологию NUMA-узлов виртуальной машины (по количеству и размеру). Это приводит к тому, что CPU и память стараются взаимодействовать друг с другом в рамках одного NUMA-узла, что приводит к наименьшим задержкам при выполнении операций.

В VMware для измерения численных показателей потерь производительности при включении Hot Add решили взять бенчмарк DVD Store 3 (DS3), который используется для тестирования рабочих нагрузок в транзакционных базах данных (в частности нагрузок, например, интернет-магазинов). В качестве референсной базы данных использовалась БД размером 300 ГБ, а доступ к ней через драйвер DS3 производился из виртуальной машины с 20 vCPU и 32 ГБ RAM на борту.

Напомним, что для ВМ функции Hot Add включаются и отключаются в разделе Virtual Hardware > CPU > CPU Hot Plug, где есть чекбокс Enable CPU Hot Add.

При 28 vCPU в виртуальной машине и выключенном Hot Add консоль SQL Server Management Studio видит 2 NUMA-узла:

При включенном - только один NUMA-узел:

Далее были запущены стандартные тесты для обеих конфигураций с постепенным увеличением числа потоков для воркеров (threads), где главным критерием производительности было число операций в минуту (orders per minute, OPM). В итоге получилась вот такая картина:

Результат - включение Hot Add снизило производительность на 2-8% в зависимости от числа потоков. Поэтому включать Hot Add для виртуальной машины нужно только тогда, когда вам точно нужно именно горячее добавление vCPU или vRAM для этой ВМ.

В сентябре этого года мы писали о новой версии пакета VMware Tools 11 для гостевых ОС виртуальных машин на платформе VMware vSphere. Одной из новых возможностей обновленной версии тулзов был читаемый с хоста параметр AppInfo для публикации информации о запущенных приложений внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается). 

Недавно Вильям Ламм пояснил, как именно может работать этот механизм, который дает возможность получить данные о процессах в гостевой ОС и их свойствах.

Для начала начала надо включить Application Discovery в гостевой ОС с помощью утилиты VMwareToolbox. По умолчанию этот механизм отключен, чтобы не создавать дополнительную нагрузку на виртуальную машину.

Для включения нужно выполнить следующую команду:

• Windows: VMwareToolboxCmd.exe config set appinfo enabled true
• Linux: vmware-toolbox-cmd config set appinfo enabled true

Выглядит это таким образом:

После того, как сбор данных включен, они будут обновляться каждые 30 минут - то есть эта функция не предназначена для мониторинга процессов в реальном времени, а скорее для сбора информации об имеющихся в ВМ приложениях и их свойствах. Чтобы изменить интервал обновления, используйте следующие команды:

• Linux: vmware-toolbox-cmd config set appinfo poll-interval <new value in seconds>
• Windows: VMwareToolboxCmd.exe config set appinfo poll-interval <new value in seconds>

Например, AppInfo может собирать информацию о версии всех приложений, что может оказаться полезным при автоматизированном поиске устаревших версий приложений с помощью сценариев.

Вильям написал PowerCLI-скрипт Get-VMApplicationInfo.ps1, который принимает на вход виртуальную машину, а на выходе выдает информацию о процессах гостевой ОС с меткой времени сбора данных.

Результат работы сценария можно вывести в CSV-файл или в JSON-массив.

Ну а дальше уже можно фантазировать, для чего подобная информация может пригодиться именно в вашей виртуальной инфраструктуре.

Осенью прошлого года мы писали об официальных стенсилах VMware для Visio, которые помогают инженерам и техническим писателям делать схемы, диаграммы и отчеты для документирования виртуальной инфраструктуры.

За прошедший год эти стенсилы и шаблоны были пару раз обновлены, поэтому рекомендуется скачать и использовать их актуальные версии. Давайте посмотрим, что нового появилось за год:

• Были добавлены примеры диаграмм с низкой и средней сложностью.
• Очень существенно были обновлены иконки продуктов и фичей.
• Пофикшены проблемы с файлом иконок vmware-sddc-icons.vssx и добавлен новый шаблон виртуального датацентра vmware-sddc-template.vsdx.

Напомним рекомендации насчет этих иконок и стенсилов в целом:

• Используйте шрифт Arial Regular.
• Сначала создавайте текстовые блоки, чтобы понять, что дизайн вписывается в максимальный размер элементов по ширине.
• Не используйте шрифт менее 11 пунктов.
• Не масштабируйте фигуры и иконки - это может привести к их искажениям.
• Не используйте другой формат страницы, это тоже может вызвать сбой в визуализации.

Скачать официальные VMware Visio Stencils 2019 можно по этой ссылке.

Вильям Ламм написал интересную статью про вывод информации обо всех доступных событиях на сервере VMware vCenter. Недавно мы писали о решении vCenter Event Broker Appliance (VEBA), которое позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That".

Так вот, администраторы, использующие VEBA, часто задают вопрос о том, как найти конкретное событие vCenter и его ID в целях автоматизации операций. Также иногда это необходимо для использования с vSphere API. Для этого Вильям написал PowerCLI скрипт, который экспортирует список всех происходивших событий vCenter в CSV-файл, где в отдельных колонках приведены EventId, EventType (может быть Standard, EventEx или ExtendedEvent) и EventDescription:

$vcenterVersion = ($global:DefaultVIServer.ExtensionData.Content.About.ApiVersion)

$eventMgr = Get-View $global:DefaultVIServer.ExtensionData.Content.EventManager

$results = @()
foreach ($event in $eventMgr.Description.EventInfo) {
    if($event.key -eq "EventEx" -or $event.key -eq "ExtendedEvent") {
        $eventId = ($event.FullFormat.toString()) -replace "\|.*",""
        $eventType = $event.key
    } else {
        $eventId = $event.key
        $eventType = "Standard"
    }
    $eventDescription = $event.Description

    $tmp = [PSCustomObject] @{
        EventId = $eventId;
        EventType = $eventType;
        EventDescription = $($eventDescription.Replace("<","").Replace(">",""));
    }

    $results += $tmp
}

Write-Host "Number of Events: $($results.count)"
$results | Sort-Object -Property EventId | ConvertTo-Csv | Out-File -FilePath vcenter-$vcenterVersion-events.csv

Пример результатов работы данного сценария как для VMware vCenter 6.7 Update 3, так и для облачной среды VMware Cloud on AWS 1.8, можно найти в репозитории по этой ссылке: https://github.com/lamw/vcenter-event-mapping.

Также можно добавить в поток событий VMware vCenter и свое собственное событие. Можно сэмулировать как стандартное событие vCenter для тестирования срабатывания алармов vCenter, так и сделать кастомное.

Вот пример сценария, который генерирует такое событие в vCenter:

$eventMgr = Get-View $global:DefaultVIServer.ExtensionData.Content.EventManager

$customEvent = New-Object VMware.Vim.EventEx
$customEvent.eventTypeId = "vGhettoWelcomeEvent"
$customEvent.message = "Hello from virtuallyGhetto"
$customEvent.ChainId = "0"
$customEvent.Key = "0"
$customEvent.CreatedTime = $(Get-Date -Format g)
$customEvent.UserName = "vGhetto-Bot"

$eventMgr.postEvent($customEvent,$null)

Это событие мы увидим в консоли VMware vCenter:

На скриншоте видно, что в поле Description отображается не то, что было задано в свойствах события. Это связано с тем, что за отображение этого поля отвечает другая подсистема. Чтобы это поле корректно отображалось для кастомных событий нужно зарегистрировать кастомное расширение (custom extension), которое будет публиковать информацию о событии. Более подробную информацию об ExtensionManager, с помощью которого это можно сделать, можно посмотреть вот тут.

Для большинства ИТ-специалистов виртуализация ассоциируется с накладными расходами на ее содержание. Виртуальная машина имеет такие-то потери по CPU и столько-то издержки по оперативной памяти. Но иногда бывает и обратная ситуация - например, в статье про производительность контейнеров на платформе Project Pacific утверждается, что в виртуальных машинах они работают на 8% быстрее, чем на голом железе с Linux на борту.

Давайте посмотрим, почему это может быть так.

Сначала для тестирования взяли 2 идентичных аппаратных конфигурации (кластер из двух узлов), на одной из которых развернули гипервизор ESXi на платформе Project Pacific (там Kubernetes pods работают в виртуальных машинах), а на второй поставили Linux с Kubernetes pods (видимо, подразумевается Red Hat) с настройками из коробки, которые работают нативно:

VMware объясняет высокую производительность Project Pacific тем, что гипервизор воспринимает Pods как изолированные сущности, которые можно адресовать на CPU для наиболее подходящих локальных NUMA-узлов. Планировщик ESXi уже давно умеет эффективно работать с NUMA-узлами для vCPU ВМ, поэтому вполне логично ожидать здесь хороших результатов.

При настройке Kubernetes на Linux пользователь, с точки зрения выделения ресурсов CPU, оперирует логическими ядрами, которые дает технология hyperthreading, а при настройке виртуальных машин - физическими pCPU, то есть физическими ядрами процессора. Поэтому для чистоты эксперимента в тестах производительности VMware отключала hyperthreading.

Конфигурация каждого Pod выглядела так:

Всего было развернуто 10 Kubernetes pods, каждый из которых имел лимит по ресурсам 8 CPU и 42 ГБ RAM. Далее там был запущен один из Java-бенчмарков, целевым показателем которого была полоса пропускания (maximum throughput).

Результат оказался следующим:

Из графика видно, что кластер vSphere дал на 8% лучше результаты, чем нативный кластер Kubernetes на Linux.

Чтобы понять механику процесса, VMware замерила число попаданий в local DRAM (на уровне локального NUMA-домена) по сравнению с remote DRAM при условии промаха кэша в L3 процессора.

Для ESXi число таких попаданий составило 99,2%:

Это означает, что планировщик ESXi умеет размещать процессы ВМ таким образом, чтобы они могли получать более быстрый доступ к local DRAM.

Если же использовать привязку узлов к NUMA-доменам (Numactl-based pinning) в Linux, то результат работы нативных контейнеров выглядит лучше, чем таковой в виртуальных машинах:

Между тем, такая жесткая привязка узлов Kubernetes к NUMA-узлам оказывается непрактичной, когда требуется развертывать большое количество контейнеров, и возникает большая вероятность ошибок в конфигурациях.

Поэтому из коробки получается, что контейнеры Project Pacific работают лучше, чем на Linux-платформе в контексте использования ресурсов CPU.

Некоторое назад мы детально рассказывали о продукте VMware Project Pacific, который был анонсирован на конференции VMworld 2019 в Сан-Франциско. Это решение является частью семейства продуктов VMware Tanzu, разработанного специально для создания единой платформы для контейнеризованных приложений и виртуальных машин, которые сейчас очень часто совместно работают в инфраструктуре крупных предприятий.

На днях компания VMware зарелизила небольшие обновления компонентов платформы виртуализации vSphere 6.7 Update 3b. Release notes для vCenter 6.7 Update 3b можно посмотреть тут, а для ESXi 6.7 Update 3b - тут.

Нововведений особо никаких в новых апдейтах нет, в основном это фиксы подсистемы безопасности, которые регулярно выходят для всех компонентов VMware vSphere. Хотя один стоящий внимания багофикс все же есть - это исправление ошибки "After you revert a virtual machine to a snapshot, change block tracking (CBT) data might be corrupted". То есть, снова возрождался баг о том, что данные, резервируемые с использованием трекинга изменившихся блоков CBT (а это используют все системы резервного копирования), могут оказаться поврежденными.

Напомним, что прошлый апдейт пакета (vSphere 6.7 Update 3a) также не содержал существенных обновлений.

Скачать компоненты платформы VMware vSphere 6.7 Update 3b можно по этой ссылке.

Оказывается, мы не рассказывали про бесплатный, но очень интересный сервис VMware, основанный на механике продукта vRealize Operations, который предоставляет различную информацию о виртуальной инфраструктуре - vSphere Optimization Assessment (VOA).

С помощью данного сервиса можно получить представление о производительности и конфигурациях виртуальной среды для разных облачных сред в рамках единой консоли. VOA позволят представить самые важные данные в формате четырех видов отчетов:

• Configuration Report - этот отчет указывает на несоответствия конфигураций на различных уровнях, таких как виртуальные машины, хосты, кластеры и виртуальные сети.

Вот пример такого отчета:

• Performance Report - в этом отчете идентифицируются и локализуются проблемы, которые могут затронуть ваши приложения. Из отчета можно получить некоторую информацию о корневой причине возникших проблем с производительностью.

Пример этого отчета:

• Capacity and Cost Report - отчет, который позволяет получать информацию об использовании емкостей и принимать решения о масштабировании виртуальной среды. Помимо этого, он дает информацию о необходимости высвобождения хранилищ и выдает тренды утилизации емкостей, чтобы вы не попали в ситуацию неожиданной нехватки ресурсов и падения производительности. Кроме того, в отчете содержится информация о стоимости таких операций по высвобождению ресурсов и процессов расширения инфраструктуры.

Пример этого отчета:

• Analyze Events Report - тут показаны инсайты на основе сработавших алертов в вашей виртуальной инфраструктуре. Здесь фокус делается не на всех алертах, а только на тех, что требуют вашего внимания.

Пример этого отчета:

Получить доступ к сервису vSphere Optimization Assessment (VOA) могут все клиенты платных версий VMware vSphere по этой ссылке.

Большинство сценариев PowerCLI начинаются с команды Connect-VIServer. Она позволяет соединиться с нужным сервером VMware vCenter и исполнять там необходимые сценарии.

Если вы работаете только с одним сервером vCenter, то нужно лишь один раз соединиться с сервером и после этого выполнять там команды без его указания. Для удобства работы в таких окружениях разработчики обычно прописывают глобальную переменную $global:DefaultVIServer, где указывают сервер vCenter по умолчанию. Это дает возможность исполнять командлеты без указания сервера vCenter, который будет подставляться из глобальной переменной.

Если из сценария PowerCLI вы соединяетесь с несколькими серверами vCenter одновременно, то для выполнения команды на нужном vCenter, надо указать его явно:

Get-VM -Server vcenter1.domain.local

В то же время, если вы пользуетесь глобальной переменной DefaultVIServer, вы можете попасть в ситуацию, когда использование ее станет невозможным, поскольку она очищается при дисконнекте от сервера vCenter. Рассмотрим пример:

Connecting to vCenter server vcenter1.domain.local

DefaultVIServer value: vcenter1.domain.local

Connecting to vCenter server vcenter2.domain.local

DefaultVIServer value: vcenter2.domain.local

Disconnecting from vCenter server vcenter2.domain.local

DefaultVIServer value:

Get-VM : 29/11/2019 6:17:41 PM Get-VM You are not currently connected to any servers. Please connect first using a Connect cmdlet.

Мы видим, что при отключении от сервера vCenter2 произошла очистка переменной DefaultVIServer, поэтому при попытке вызвать командлет Get-VM возникла ошибка. При этом текст ошибки об отсутствии соединения вводит в заблуждение и не соответствует фактической ситуации. Ведь подключение к серверу vCenter1 осталось, просто отсутствует значение этого сервера в переменной DefaultVIServer.

Чтобы работать с несколькими серверами vCenter одновременно, в окружении PowerCLI есть режим Multiple DefaultVIServer mode, который позволяет использовать массив DefaultVIServers.

Перейти в этот режим можно командой:

Set-PowerCLIConfiguration -DefaultVIServerMode Multiple

После перехода в этот режим все команды без указания параметра -Server будут исполняться на всех подключенных серверах vCenter (это надо иметь в виду), присутствующих в массиве DefaultVIServers.

Если же другие пользователи будут выполнять ваш скрипт в режиме Single connection mode, то он может исполняться некорректно или вылететь с ошибкой, поэтому явно указывайте режим Multiple DefaultVIServer mode в самом начале скрипта.

Недавно компания VMware выпустила обновленную версию платформы VMware Integrated OpenStack 6.0. Напомним, что она предназначена для построения инфраструктуры OpenStack на базе платформы виртуализации VMware vSphere путем развертывания виртуального модуля vSphere OpenStack Virtual Appliance (VOVA). О прошлой версии Integrated OpenStack 5.0 мы писали вот тут.

Давайте посмотрим, что нового в Integrated OpenStack 6.0:

1. Панель управления с использованием Kubernetes.

Теперь в Integrated OpenStack 6.0 есть возможность использования консоли поверх кластера Kubernetes. Сервисы OpenStack теперь развертываются как узлы (Pods) Kubernetes, что позволяет их горизонтально масштабировать бесшовно и независимо друг от друга.

2. Kubernetes для множества клиентов.

Панель управления OpenStack за счет использования Essential PKS позволяет управлять инфраструктурой, где одновременно работают несколько независимых клиентов. Референсная имплементация этого решения средствами Heat доступна на сайте проекта на GitHub.

3. Улучшения Cinder.

• Возможность привязать том сразу к нескольким инстансам.
• Поддержка vSphere First Class Disk (FCD).

4. Улучшения IPv4/IPv6 и Dual Stack.

• Поддержка Dual stack IPv4/IPv6 для инстансов Nova и групп Neutron.
• Поддержка IPv6 с решением NSX-T 2.5 и плагином NSX-P Neutron.
• Режимы адресации IPv6: статический и SLAAC.
• Статическая маршрутизация IPv6 для маршрутизаторов Neutron.
• Поддержка IPv6 для FWaaS.

5. Улучшения Keystone.

• Поддержка федерации через токены JSON Web Tokens (JWT).

6. Улучшения масштабируемости.

Теперь VIO 6.0 позволяет горизонтально масштабировать контроллеры, также как и узлы (pods), которые работают в этих контроллерах. Компактное развертывание использует 1 контроллер, а HA-развертывание - 3 контроллера. Итого можно масштабировать развертывание до 10 контроллеров для высоконагруженных окружений.

7. Функции Essential PKS on OpenStack.

• Единая платформа для гибридных виртуальных машин и контейнеров.
• Интерфейс OpenStack и Kubernetes API для управления жизненным циклом ресурсов и кластера.
• Возможность развернуть Essential PKS с компонентом OpenStack Heat.
• Поддержка OpenStack multi-tenancy для безопасной изоляции контейнерных сред.
• Пакет VMware Certified Kubernetes, который находится в рамках референсной архитектуры с Essential PKS.

8. Улучшения инструментов управления.

• viocli переписан на Golang.
• Функции Bash completion и ярлыки CLI shortcuts добавлены в Life Cycle Manager.
• Интерфейс HTML5 WebUI:
  • Нет зависимости от плагина vCenter Web Plugin.
  • Поддержка нативных тем Clarity.

9. Функции ОС Photon 3.

• Панель управления VIO использует VMware Photon OS версии 3 - более легковесную и безопасную.
• Контейнеры также построены на базе образов Photon OS 3.

10. Улучшения API.

• Закрытый OMS API заменен на стандартный Kubernetes API.
• Многие части VIO могут управляться через команды kubectl в дополнение к viocli.
• Новый Cluster API, отвечающий за дополнительное управление ВМ.

11. Мониторинг.

• Функции анализа причин проблем в движке Smart Assurance.
• Операционный мониторинг с помощью дэшбордов vROps OpenStack Dashboards и Container monitoring.
• Интеграция с vRealize Log Insight.
• Видимость физических и виртуальных сетей OpenStack.
• Еще большая автоматизация поиска операционных проблем.

12. Прочие улучшения.

• Автоматизированные резервные копии VIO.
• Управление жизненным циклом компонентов OpenStack.
• Встроенный контроль версий конфигураций.
• Тема для визуального фреймворка Clarity.
• Поддержка OpenStack Helm для развертывания компонентов OpenStack.

Кроме того, VMware выпустила четыре интересных видео, посвященных новым возможностям Integrated OpenStack 6.0:

1. Развертывание VIO 6.0:

2. Апгрейд с версии 5.1 на 6.0:

3. Работа VMware Essential PKS поверх VMware Integrated OpenStack 6.0:

4. Интеграция VIO 6.0 с решениями vRealize Operations Manager и vRealize Log Insight:

Скачать VMware Integrated OpenStack 6.0 можно по этой ссылке. Более подробно о платформе написано в Release Notes.

В сентябре этого года мы писали о том, что компания VMware сделала доступным очень полезный онлайн-ресурс ports.vmware.com, в котором администраторы могут посмотреть порты и соединения для различных продуктов, таких как vSphere, vSAN, NSX и прочих. На тот момент на сайте было представлено всего 6 продуктов. С тех пор сайт регулярно обновлялся, и теперь пользователи VMware могут вывести таблицы портов уже по 12 решениям:

• vSphere
• vSAN
• NSX Data Center for vSphere
• vRealize Network Insight
• vRealize Operations Manager
• vRealize Automation
• vCloud Availability
• vCloud Usage Meter
• VMware HCX
• Horizon 7
• Workspace ONE Access
• Site Recovery Manager

В левой части можно выбрать один или несколько продуктов, для которых будут выведены все соединения с указанием портов, протокола и назначения взаимодействий с подробным описанием (а также направление взаимодействия). Это позволит правильно настроить сетевые экраны, через которые происходит коммуникация между компонентами виртуальной инфраструктуры.

Результаты можно экспортировать в отдельный красивый PDF-документ, либо распечатать. Что удобно, в колонке Version указана версия продукта, для которой эта информация актуальна. Обратите внимание также на гиперполезную функцию поиска по результатам вывода.

Пользуйтесь: https://ports.vmware.com

Многим администраторам VMware vSphere иногда требуется собрать некоторые базовые сведения об имеющихся в виртуальной инфраструктуре виртуальных машинах и их гостевых системах. Традиционные способы сбора такой информации применимы лишь частично - ведь стандартный софт для собора ассетов не может взглянуть внутрь хостов ESXi и задокументировать их внутреннюю структуру. Также надо понимать, что софт, использующий ICMP-протокол (а именно команду ping) также не подходит для этой задачи, так как далеко не все системы сегодня отвечают на пинг.

Давайте посмотрим на способы, которые доступны для этой задачи:

1. Функция экспорта в vSphere Client.

Это самое первое, что вам следует сделать для решения проблемы инвентаризации ассетов в виртуальной среде. Кнопка экспорта находится в нижнем правом углу инвентори клиента. С помощью этой фичи можно выгрузить любое представление с нужными колонками в формат CSV:

Здесь вы сможете выгрузить то, чего больше не сможете выгрузить нигде, например, сведения о поддержке TPM, функциях безопасной загрузки Secure Boot для ESXi и гостевых ОС, поддержке Microsoft Device Guard & Credential Guard и функций шифрования VM Encryption.

2. Экспорт через PowerCLI.

PowerCLI, как вы знаете, может все, что может GUI, плюс несколько больше. Поэтому он вам может понадобиться для расширенных параметров виртуальной среды. Основные шаблоны для работы с PowerCLI можно найти здесь.

Вот так, например, работают командлеты Get-VM и Get-VMGuest:

А вот так Get-VMHost:

Результаты работы можно сохранить в текстовый файл с помощью командлета Out-File или в CSV-файл с помощью Export-Csv.

3. Утилита nmap.

Эта утилита знакома всем сетевым администраторам, ведь ей уже более 20 лет. Ее используют как в физической, так и в виртуальной среде для сбора информации о системах и сервисах, висящих на соответствующих портах. Для Linux систем утилита часто поставляется в комплекте дистрибутива, для Windows она доступна тут.

Вот такой командой можно просканировать подсеть:

nmap -sn 192.168.1.0/24

Помните, что такое сканирование может привлечь внимание систем безопасности, и к вам обязательно придет сотрудник соответствующей службы, если такая у вас в компании есть)

4. Утилита RVTools.

Мы часто пишем об этой утилите (последний раз писали тут). Она предназначена для помощи администраторам при выполнении рутинных операций с виртуальной инфраструктурой VMware vSphere в различных аспектах, в том числе документировании.

Вот так выглядит инвентаризация виртуальных машин:

Удобно, что результаты можно сохранить не только в CSV, но и в нативный Excel-формат.

5. Утилита vDocumentation.

Об этой утилите мы писали вот тут. По сути, это набор сценариев, который позволяет через PowerCLI сгенерировать отчетность в форматах CSV или XLS, посвященную различным сторонам виртуальной инфраструктуры (сеть, хосты, кластеры vSAN и т.п.).

6. Утилита vCheck.

Об этой утилите для VMware vSphere мы уже писали вот тут. Кстати, недавно вышла ее версия для инфраструктуры виртуальных ПК VMware Horizon. vCheck - это PowerCLI-скрипт, который готовит отчетность по объектам окружения VMware vSphere и отсылает результат на почту администратора, из которого можно узнать о текущем состоянии виртуальной инфраструктуры и определить потенциальные проблемы.

Бесспорно, всего этого достаточно для сбора сведений об объектах виртуальной инфраструктуры, но не забывайте, что нужно еще иногда инвентаризировать и прочие объекты - интерфейсы iLO/iDRAC, физические коммутаторы, аппаратные сетевые экраны и прочие системы в датацентре.

В сентябре этого года мы рассказывали о возможностях новой версии решения для мониторинга и защиты сетевой составляющей виртуальной среды VMware vRealize Network Insight 5.0 (vRNI). Напомним, что это решение позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

В рамках прошедшего VMworld Europe 2019 компания VMware анонсировала обновление этой платформы - vRNI 5.1. Давайте посмотрим, что в этом решении появилось нового.

Во-первых, VMware продолжает улучшать функции SD-WAN, которые появились в продукте благодаря технологиям купленной компании VeloCloud. В духе фичи Virtual Network Assessment for NSX, версия vRNI 5.1 имеет функцию SD-WAN Assessment. Она анализирует трафик и данные из имеющейся невиртуализированной сети WAN и рассчитывает возврат инвестиций, если вы решите вложить деньги во внедрение решения SD-WAN.

Во-вторых, VMware добавила в vRNI новый дэшборд - VMware Cloud on AWS dashboard. Он позволяет вести мониторинг среды AWS в контексте концепции software defined data center (SDDC) и поддерживает компонент AWS Edge firewall, что дает возможности просмотра правил и их маппинга на сетевые потоки.

Третья интересная возможность vRNI 5.1 - функции для операций ежедневного обслуживания (Day-2 operation), такие как просмотр общего состояния инфраструктуры приложений, возможность просмотра упавших по скорости потоков, анализ трафика и другие средства, доступные в Application Dashboard.

Четвертая новая фича - поддержка физического NAT при анализе пути VM-VM, а также поддержка аппаратного Arista VTEP.

Ну и последняя новая возможность vRNI 5.1 - это улучшение функций для операций ежедневного обслуживания для решения VMware NSX-T, а также доработанные средства визуализации развернутых и затронутых изменениями компонентов.

Решение VMware vRealize Network Insight 5.1 пока нельзя скачать, но в скором времени VMware обещает его публичную доступность.

Как вы знаете, на этой неделе проходит крупнейшая конференция о виртуализации в Европе - VMworld Europe 2019. О прошедших анонсах старшей ее сестры - VMworld 2019 - мы говорили вот тут.

На этой неделе мы писали о Skyline Health for vSAN, а сегодня мы расскажем еще об одной полезности - виртуальном модуле vCenter Event Broker Appliance (VEBA), который стал доступен на VMware Labs сразу после анонса.

Сервис VEBA позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That".

Также VEBA дает решения для более серьезных интеграций, таких как Slack или Pager Duty, которые можно разрабатывать отдельно, используя предоставляемые инструменты. Уже довольно давно нечто подобное сделала компания Amazon в рамках решения AWS Lambda для своей облачной инфраструктуры.

Виртуальный модуль VEBA в формате виртуальной машины можно развернуть в любом виртуальном окружении - в частном или публичном облаке на базе VMware vSphere, например, VMware Cloud on AWS или VMware Cloud on Dell-EMC.

С помощью этого инструмента программистам не нужно глубоко нырять в логику происхождения событий и понимать структуру API, к ним относящимся. За счет этого скорость разработки существенно повышается.

Скачать VMware vCenter Event Broker Appliance можно по этой ссылке.

На сайте проекта VMware Labs недавно появилась очередная интересная штука - средство Virtualized High Performance Computing Toolkit. С помощью этого пакета пользователи VMware vSphere, которым требуется поддержка виртуальных машин, работающих в сфере высоких нагрузок (High Performance Computing, HPC), могут упростить управление жизненным циклом таких специализированных конфигураций через vSphere API.

Как правило, задачи HPC требуют использования таких технологий, как vGPU и FPGA, а также RDMA interconnects для высокопроизводительных вычислений. Помимо возможностей управления конфигурациями, тулкит содержит средства, которые дают администраторам возможности по выполнению типовых задач в HPC-окружениях на виртуальной платформе - клонирование ВМ, определение Latency Sensivity, сайзинг машин по vCPU и памяти, а также некоторые другие.

Вот возможности Virtualized High Performance Computing Toolkit списком:

• Настройка устройств PCIe в режиме DirectPath I/O с использованием GPGPU, FPGA и RDMA interconnects.
• Настройка NVIDIA vGPU.
• Настройка RDMA SR-IOV (Single Root I/O Virtualization).
• Настройка  PVRDMA (Paravirtualized RDMA).
• Возможность простого создания и удаления виртуальных кластеров HPC с использованием файлов конфигурации.
• Выполнение частых задач vSphere - клонирование ВМ, настройка vCPU, памяти, резерваций, shares, Latency Sensitivity, коммутаторов Distributed Virtual Switch/Standard Virtual Switch, сетевых адаптеров и конфигураций.

С помощью тулкита вы сможете применить приведенные выше операции к одной или нескольким ВМ одновременно. Например, вот так выглядит клонирование машины на базе шаблона vhpc_clone с заданными кастомизациями памяти и CPU и добавление NVIDIA vGPU в соответствии с профилем vGPU по имени grid_p100-4q:

vhpc_toolkit> clone --template vhpc_clone --datacenter HPC_Datacenter --cluster COMPUTE_GPU_Cluster --datastore COMPUTE01_vsanDatastore --memory 8 --cpu 8 –-file VM-file

vhpc_toolkit> vgpu --add --profile grid_p100-4q --file VM-file

В файле VM-file должен содержаться список клонов ВМ, которые должны получиться в результате операции.

А вот такой командой можно собрать кластер под HPC-задачи в соответствии с конфигурацией, указанной в файле cluster.conf:

vhpc_toolkit> cluster --create --file cluster.conf

Больше подробностей об этом тулките можно получить в репозитории на GitHub вот тут. Скачать Virtualized High Performance Computing Toolkit можно там же.

Project Pacific был одним из главных анонсов конференции VMworld в этом году, и VMware обращала на него особенное внимание. Это неудивительно - ведь VMware делает поддержку Kubernetes не для галочки. Тут дело в том, что многие пользователи планируют развертывание инфраструктуры контейнеризованных приложений на физической инфраструктуре - в этом случае не надо нести издержки на гипервизор и лицензии, а сами приложения в контейнерах работают быстро и имеют встроенные средства обеспечения доступности.

На днях компания VMware выпустила несколько небольших апдейтов своих продуктов. Во-первых, обновился управляющий сервер vSphere до версии VMware vCenter 6.7 Update 3a. В этом релизе новых возможностей не появилось, но было сделано несколько важных багофиксов. Они касаются подсистемы безопасности для процесса резервного копирования и восстановления vCenter (подробнее тут), а также компонентов Platform Services Controller и vSAN.

Скачать VMware vCenter 6.7 Update 3a можно по этой ссылке.

Во-вторых, обновился пакет для гоствых ОС - VMware Tools. Обновилась как одиннадцатая версия пакета VMware Tools 11.0.1 (напомним, что мы писали о VMware Tools 11), так и вышли VMware Tools 10.3.21 (эта ветка сделана для старых Linux-дистрибутивов).

Для тех, кто использует возможность "native service discovery" в vRealize Operations Manager 8.0, или использует продукт vRealize Operations Service Discovery Management Pack с прошлыми версиями vRealize Operations Manager (7.x или старше), обновление обязательно! Подробнее об этом написано в KB 75122.

Скачать VMware Tools 11.0.1 можно по этой ссылке, а 10.3.21 - по этой.

На днях компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 11.5. Напомним, что о прошлой версии, PowerCLI 11.4, мы писали в конце августа этого года.

Давайте посмотрим, что интересного появилось в PowerCLI 11.5:

1. Новые командлеты для управления библиотеками Content Library.

В последних версиях VMware vSphere функциональность библиотек Content Library была существенно доработана (кстати, это был один из первых сервисов, использовавших vSphere Automation REST API). PowerCLI старается не отставать, поэтому тут было добавлено 8 новых командлетов, а также была добавлена поддержка шаблонов (templates):

• New-ContentLibraryItem
• Set-ContentLibraryItem
• Remove-ContentLibraryItem
• Export-ContentLibraryItem
• New-ContentLibrary
• Set-ContentLibrary
• Get-ContentLibrary
• Remove-ContentLibrary

Вот пример опроса содержимого объекта библиотеки:

2. Обновление механизма vCenter Alarm Management.

В PowerCLI уже имеются средства для управления алармами vCenter, но их пользователям явно недостаточно. Новая версия PowerCLI имеет 6 новых и 3 обновленных командлета для управления определениями алармов, триггерами, а также для получения данных о типах событий и метриках.

Новые командлеты:

• New-AlarmDefinition
• Remove-AlarmDefinition
• New-AlarmTrigger
• Get-AlarmTrigger
• Get-EventType
• Get-Metric

Обновленные командлеты:

• New-AlarmAction
• New-AlarmActionTrigger
• Set-AlarmDefinition

Вот пример работы нового командлета, где создается определение аларма в vCenter:

3. Обновление модуля VMware Cloud on AWS.

Модуль для управления VMware Cloud on AWS (VMC) - это один из самых новых модулей. Ранее он использовался как средство низкоуровневого взаимодействия с инфраструктурой VMC. Теперь же этот низкоуровневый интерфейс был заменен на высокоуровневые команды для осуществления операций, необходимых пользователю.

Пример - теперь для создания объекта SDDC используется 1 команда вместо 20 строчек кода, которые требовались раньше:

А вот, собственно, новые командлеты, которые появились для VMC (подробнее - здесь):

• Get-VmcSddc
• Set-VmcSddc
• New-VmcSddc
• Remove-VmcSddc
• Add-VmcSddcHost
• Remove-VmcSddcHost
• Get-AwsAccount
• Get-AwsVpcSubnet

4. Обновленный модуль VMware Core.

Здесь, прежде всего, была доработана функциональность, связанная с тэгами. Командлет Get-Tag и параметр Tag для Get-VM были обновлены, также были обновлены и командлеты Get/Remove-TagAssignment.

Кроме того, базовые функции обогатились некоторыми полезными функциями. Например, теперь при создании виртуальной машины из шаблона средствами командлета New-VM появилась возможность настройки портгруппы через параметры NetworkName или Portgroup.

Также в vSphere 6.7 появилось новое свойство виртуальной машины CreateDate, которое теперь также поддерживается в командлетах, связанных с виртуальной машиной:

Больше информации о новых возможностях VMware PowerCLI 11.5 можно почерпнуть в следующих документах:

• VMware PowerCLI Change Log
• VMware PowerCLI 11.5.0 User’s Guide
• VMware PowerCLI 11.5.0 Cmdlet Reference

Update-Module -Name VMware.PowerCLI

Скачать VMware PowerCLI 11.5 можно по этой ссылке.

Интересно наблюдать за тем, какими темпами компания VMware наверстывает упущенное по наращиванию функциональности мобильного клиента для VMware vSphere. Еще совсем недавно мы писали о версии 1.5, а на днях был выпущен уже обновленный VMware vSphere Mobile Client 1.6.

Давайте посмотрим, что там появилось нового:

• Хосты ESXi теперь можно перезагружать из интерфейса мобильного клиента.
• Последние задачи теперь можно видеть в представлении Tasks (статусы running/in-progress).
• Был проведен редизайн карточек объектов (ВМ, хост, кластер и задача).
• Быстрые действия с объектом теперь можно вывести по тапу на него.
• Карточка виртуальной машины содержит скриншот гостевой ОС, который можно увеличить, тапнув на него.
• На дэшборд был добавлен портлет обратной связи, который позволяет написать разработчикам отзыв о приложении.
• Для хостов ESXi теперь доступы графики производительности.
• Меню навигации было укрупнено, поэтому теперь проще попадать по его элементам.

Скачать обновленный vSphere Mobile Client 1.6 можно по этим ссылкам:

• Android (доступно как Early access приложение).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.

Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах Intel (например, Meltdown и Spectre), которые потенциально могли приводить к получению контроля над исполнением систем (в том числе виртуальных машин), работающих на базе определенных CPU. Об этом можно прочитать у нас, например, тут и тут.

При обнаружении таких уязвимостей Intel выпускает обновления микрокода (firmware) для своих процессоров, которые нужно применить как к серверам ESXi, так и к виртуальным машинам. Например, для устранения уязвимости типа MDS была добавлена инструкция MD_CLEAR, которую гостевая ОС может обнаружить и использовать для защиты от определенных уязвимостей.

В виртуальной среде виртуальная машина - это VMX-процесс на сервере ESXi, который обеспечивает исполнение гостевой операционной системы. При этом ВМ может перемещаться между серверами ESXi средствами vMotion, поэтому она может иметь довольно большой аптайм (больше самих хостов, где она работает) и, как следствие, долго не обновлять виртуальное аппаратное обеспечение.

В то же время, для патчинга некоторых уязвимостей нужно обновить микрокод CPU и пересоздать VMX-процесс виртуальной машины, чтобы она могла инициализировать и подхватить обновления микрокода (что происходит только при первой загрузке). Простая перезагрузка тут не поможет, так как в этом случае пересоздания VMX не происходит, а лишь идет ребут гостевой системы. Кстати, это вам на заметку - если хотите "почистить" виртуальную машину, то лучше выключить и включить ее, а не перезагружать.

Чтобы выполнить процедуру выключения и включения, начиная с vSphere 6.5 Update 3 и vSphere 6.7 Update 3, компания VMware ввела инструкцию vmx.reboot.PowerCycle, которая выполняет цикл питания виртуальной машины. Этот параметр, который можно добавить в VMX-файл, считывается со стороны VMware Tools, которые уже совместно с хостом ESXi обеспечивают исполнение этого цикла.

Чтобы добавить этот параметр в VMX-файл через PowerCLI, вы можете использовать следующую команду:

New-AdvancedSetting -Entity YOUR_VM_NAME -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Это же можно сделать и для групп виртуальных машин, например, находящихся в папке Test Group 1:

Get-Folder "Test Group 1" | Get-VM | New-AdvancedSetting -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.

После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.

Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):

Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.

В случае, если у вас где-то поменялось железо на хостах, то нужно выполнить перезапуск цикла питания виртуальных машин, что приведет кластер EVC к единому базовому уровню и позволит избавиться от потенциальных проблем.

На сайте VMware обновился основной документ Product Lifecycle Matrix, в котором приведены дата доступности продукта для загрузки, окончание поддержки, завершение технического сопровожнения и дата снятия с продаж.

Документ обновился совсем недавно и актуален на 1 октября 2019 года (кстати, обращайте внимание на колонку Notes и расшифровку этих заметок в конце документа):

Для каждого из продуктов приведен тип политики поддержки по отношению к обслуживанию жизненного цикла серии продуктов. VMware разделяет эти политики на следующие типы:

• APP: - Application Platform Policy
• EAP: - Enterprise Application Policy
• EDP: - Enterprise Desktop and Mobility Policy
• EIP: - Enterprise Infrastructure Policy
• GSP: - General Support Policy
• N-2: - N-2 Policy
• N/A: - No lifecycle policy applies
• PDP: - Personal Desktop Policy
• VI3P: - VMware Infrastructure 3 Policy

Скачать VMware Product Lifecycle Matrix можно по этой ссылке. Если у вас большая инфраструктура, где есть продукты довольно древних версий, то будет полезным занести в закладки этот документ, чтобы понимать, когда нужно запланировать обновление, чтобы не остаться без поддержки от вендора.

Довольно интересная штука обнаружилась среди бесплатных средств для мониторинга виртуальной инфраструктуры VMware vSphere - утилита с неблагозвучным названием LPAR2RRD. Оказывается на днях вышла ее версия 6.1, где появилось несколько новых возможностей.

Сама утилита LPAR2RRD - это бесплатное средство мониторинга для сред VMware vSphere и IBM Power Systems без агентов, которое позволяет отслеживать различные аспекты производительности хостов и виртуальных машин. Если же поставить агенты в ОС, то решение будет работать и с такими системами, как AIX & Linux, IBM i (AS/400) и Solaris.

Полнофункциональное демо этого продукта доступно по этой ссылке.

Надо отметить, что продукт вполне развивается и обновляется разработчиками, несмотря на свою бесплатность. В данном решении есть следующие основные возможности для мониторинга сред VMware vSphere:

• Мониторинг ресурсов
  • vCenter
  • Cluster
  • Resource Pool
  • Datastore
  • ESXi
  • Virtual Machine
• Метрики мониторинга
  • Производительность CPU (GHz, число CPU, показатель CPU ready)
  • Использование памяти (reserved, granted, consumed, active, baloon, swap in, limit)
  • Производительность LAN в МБ/сек
  • Производительность дисковой подсистемы (МБ/сек, IO per sec, latency в миллисекундах)
  • Использование дисков (ГБ)
• Другие возможности
  • Функция Trends
  • Исторические отчеты
  • Функции Heatmap
  • Возможность масштабирования графиков

Для тех, кто знаком с этим решением, вот список новых возможностей LPAR2RRD 6.1, вышедшей в октябре:

• Новый раздел Dashboard - полностью кастомизабельное пространство для графиков и диаграмм. Пользователь может менять размер графиков, создавать группы и двигать графики между ними.
• Раздел Heatmap - добавлена визуализация в сортируемых и фильтруемых таблицах.
• Улучшенная конфигурация через REST API для IBM Power Systems в части виртуальных сетей vSCSI и NPIV.
• Поддержка папок для vSphere (VM, Datastores).
• Таблица использования пространства виртуальными машинами в кластере (VM SPACE).
• Поддержка формата CSV в компоненте Reporter.
• Структура меню Hyper-V консолидирована по использованию ресурсов на вкладках вместо подразделов меню.
• Поддержка Solaris: мониторинг пулов.
• Reporter: поддержка Solaris и Hyper-V.
• Reporter: поддержка функционала TOP10 (графики можно вывести в pdf).
• Reporter: доступен файл с рекомендациями конфигурации в формате CSV.
• Поддержка кастомных групп для Hyper-V.
• Улучшения контроля доступа (ACL) - роль read-only.
• Множество небольших улучшений и багофиксов для следующих платформ:
  • IBM Power Systems: HMC REST API
  • Oracle Solaris
  • Microsoft Windows и Hyper-V

Скачать LPAR2RRD можно абсолютно бесплатно в виде виртуального модуля (Virtual Appliance) вот здесь.

На сайте проекта VMware Labs появилась обновленная версия мобильного клиента для управления виртуальной инфраструктурой - VMware vSphere Mobile Client 1.5. Напомним, что о версии 1.3 мобильного клиента мы писали вот тут.

Давайте посмотрим, что нового в vSphere Mobile Client версий 1.4 и 1.5 (кстати, в Changelog версия 1.5 была ошибочно обозначена также как 1.4):

• Теперь поддерживаются прямые соединения к хостам ESXi, а не только через vCenter.
• Хост ESXi можно перевести в режим обслуживания (maintenance mode).
• Новое представление Cluster View, где видны события кластера.
• Появился диалог подтверждения при быстрых операциях с виртуальными машинами.
• Карточка кластера теперь показывает имеющиеся проблемы, статус DRS и HA, а также число событий vMotion.
• Карточка хоста ESXi показывает имеющиеся проблемы, число виртуальных машин, текущий аптайм и статус соединения.
• Выход из деталей ВМ обратно не обновляет страницу.
• Множество исправлений ошибок.

Скачать обновленный vSphere Mobile Client 1.5 можно по этим ссылкам:

• Android (в комбобоксе загрузки просто выберите apk-файл).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.

Перед проходившей недавно конференцией VMworld 2019 компания VMware объявила об обновлении платформы VMware HCX Enterprise, которая теперь позволяет проводить миграции с различных опремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud. Давайте посмотрим, как устроено это решение.

Ранее VMware HCX (расшифровывается как Hybrid Cloud Extension) мог сопровождать процессы миграции виртуальных машин vSphere из локального датацентра в облачную инфраструктуру сервис-провайдеров VCPP или публичных облаков, но теперь это гораздо более функциональное средство - для миграции поддерживаются гипервизоры RedHat OpenStack/KVM и Microsoft Hyper-V. Для этого есть специальные дата муверы, которые обеспечивают процесс, называемый OS Assisted Migration (OSAM).

Много лет назад для миграций на уровне собственного датацентра можно было использовать  VMware Converter (продукт, который был незаслуженно забыт), но теперь VMware HCX Enterprise дает гораздо более широкие возможности по созданию уже гибридных инфраструктур за счет перемещения части виртуальных машин в облако и обслуживания единого пространства для существования машин в гибридной среде.

VMware HCX работает с vSphere 5.5 и более поздними версиями, а также гипервизорами KVM и Hyper-V, чтобы создать единую среду между онпремизным датацентром и облачным на основе архитектуры VMware Cloud Foundation (VCF), где работают средства по обеспечению катастрофоустойчивости рабочих нагрузок VMware Site Recovery Manager. Кстати, самыми крупными партнерами VMware в рамках программы VCPP являются IBM, OVH и Centurylink, а поддерживаемыми публичными облаками - AWS, Azure и GCP.

VMware HCX может быть первым шагом для крупных компаний в плане начала создания гибридной инфраструктуры, которая использует ресурсы нескольких облаков (то, что на картинке выше обозначено как v5). Ведь уже сейчас пользователи испытывают потребность облачных ресурсах больших публичных облаков, а также сторонних специализированных облаках, таких как Telco Clouds (на базе решений SDN / NFV).

HCX предоставляет возможность миграции виртуальных машин и приложений между различными видами облаков по принципу Any2Any. С точки зрения виртуальной машины, ее ОС и приложений, HCX выступает уровнем абстракции, который представляет машине единую гибридную среду в которой находятся все локальные и облачные ресурсы (infrastructure hybridity). Это дает возможность машинам перемещаться между датацентрами, не требуя реконфигурации самих ВМ или инфраструктуры.

Решение HCX представлено двумя компонентами:

• HCX Cloud (Target) – это машина HCX Management, которая развернута, например, в облаке VMC on AWS SDDC.
• HCX Enterprise (Source) – это ВМ, которая развертывается в онпремизном датацентре клиента.

Если вы пользуетесь услугами облака VMware vCloud on AWS, то HCX Cloud у вас готов к использованию (надо только нажать кнопку Deploy в консоли VMC). После этого вы сможете использовать HCX cloud web console, где можно скачать готовый виртуальный модуль HCX Enterprise OVA для использования уже в онпремизном датацентре. После создания конфигурации из локальной и облачных сред между ними автоматически настраивается IPsec VPN.

После этого вы сможете управлять гибридной средой с помощью HCX Manager:

HCX Enterprise в онпремизном датацентре отвечает за выполнение следующих задач:

• Создание интегрированной среды управления vCenter между облаком и онпремизным датацентром.
• Соединение площадок в единое облако HCX Cloud.
• Развертывание дополнительных компонентов (сервисных виртуальных модулей). Эти компоненты автоматически развертываются и в облаке AWS одновременно с онпремизными:
  • HCX WAN Interconnect - проводит миграцию vMotion между площадками через интернет или выделенные линии. Он также отвечает за обеспечение безопасности и шифрования. С точки зрения vCenter, это выглядит как фейковый ESXi-хост на обеих площадках, действующий как прокси для миграции ВМ между сайтами.
  • HCX WAN Optimization - отвечает за оптимизацию канала средствами дедупликации и компрессии трафика.
  • HCX Network Extension - реализует расширение L2-адресации на единое пространство с облаком, чтобы машины при миграции не требовали перенастройки MAC и IP-адресов.
• Предоставление Restful API и HCX API (к документации можно получить доступ по адресу https://<HCX Enterprise>/hybridity/docs).

На стороне публичного облака, например, vCloud on AWS, это выглядит несколько более сложно (там задействуется решение VMware NSX для обеспечения сетевой инфраструктуры), но компоненты те же:

Для инфраструктуры на базе VCPP (например, в облаке IBM) все выглядит проще (но там несколько меньше возможностей для конфигурации сетевого стека):

Помимо перечисленных основных 3 компонентов, HCX реализует еще несколько полезных сервисов, таких как пакетная миграция ВМ, средства катастрофоустойчивости (Disaster Recovery), возможности миграции с других гипервизоров (OS Assisted Migration) и прочее:

При миграции виртуальных машин между площадками есть пять типов миграций:

• VMware HCX Bulk Migration - этот метод использует средства VMware vSphere Replication для массового перемещения виртуальных машин на удаленную площадку. Потом происходит переключение обслуживания на реплики, что эквивалентно простою сервиса на период перезагрузки ВМ.
• VMware HCX vMotion - здесь применяются обычные средства vMotion для перемещения ВМ (1 машина в один момент времени, без перерыва в обслуживании).
• VMware HCX Cold Migration - это миграция остановленной машины с источника на таргет, с максимальными гарантиями сохранности данных, но простоем сервиса.
• VMware HCX Replication Assisted vMotion (RAV) - эта техника совмещает в себе преимущества HCX Bulk Migration (параллелизм операций и возможность запланированного запуска) с HCX vMotion (без прерывания сервиса). Это новый режим, появившийся в августе этого года.
• VMware HCX OS Assisted Migration - это миграция виртуальных машин с не-vSphere гипервизоров на онпремизную или облачную инфраструктуру vSphere (также новая функция HCX Enteprise).

Для мониторинга решения HCX можно использовать специальный пакет vRealize Operations Management Pack for HCX, который предоставляет интегрированные дэшборды и отчеты, а также дает всю необходимую информацию о возникающих проблемах.

Более подробно о решении HCX можно узнать на основной странице продукта. Администраторам гибридных инфраструктур VMware vSphere, использующих ресурсы различных облаков, стоит присмотреться к этому решению, так как оно существенно упрощает контроль над виртуальными машинами, которые перемещаются между датацентрами (и, конечно же, создает платформу для всего этого), а также позволяет своевременно отслеживать и решать возникающие проблемы.

Оригинал статьи на английском языке в блоге StarWind Software.

Продолжаем рассказывать (пока еще есть что!) о новых продуктах и технологиях, анонсированных на конференции VMworld 2019, которая закончилась уже почти 3 недели назад. Одна из самых интересных и перспективных технологий - это, конечно же, техника VMware Cluster Memory, которая действительно может поменять архитектуру датацентров в будущем.

Об этой технологии хорошо написал Дункан Эппинг. Как известно некоторым из вас, еще 20 лет назад скорость доступа к оперативной памяти серверов была примерно в 1000 раз выше, чем доступ к данным другого хоста по локальной сети. Шли годы, сетевой стек и оборудование улучшались - и в итоге на сегодняшний день доступ по сети всего в 10 раз медленнее, чем локальный доступ к RAM. Достигается это различными способами, в том числе технологией удалённого прямого доступа к памяти (remote direct memory access, RDMA).

Главное в этой эволюции то, что такие вещи как RDMA стали вполне доступными по цене, а значит можно обсуждать новые архитектуры на их основе. Тем более, что одной из основных проблем текущих датацентров стала трудность масштабирования инфраструктуры по памяти - ведь когда на одном из хостов не влезают виртуальные машины по RAM (например, есть машины с очень большим потреблением памяти), нужно увеличивать память и на всех остальных хостах кластера.

Поэтому VMware в рамках сессии VMworld "Big Memory with VMware Cluster Memory" рассказала о том, как можно строить кластеры с помощью так называемых "серверов памяти", которые обеспечивают работу хостов ESXi и их виртуальных машин, которым нужно дополнительное пространство памяти по требованию.

Кстати, еще есть и ограничение по объему DRAM на одном хосте - как правило, это несколько ТБ. Как мы видим на картинке выше, эту проблему можно решить созданием отдельных Memory-серверов в кластере, которые могут раздавать свою память по высокопроизводительной шине RDMA.

Технологии сетевого доступа к памяти будут развиваться, и скоро возможность использования виртуальными машинами страниц памяти с Memory-хостов будет вполне реальна:

Для этого компания VMware разработала отдельный paging-механизм, который позволяет проводить паджинацию страниц на удаленный сервер вместо локального диска, для чего будет необходим локальный кэш. При запросе страницы с удаленного сервера она сначала будет помещаться в локальный кэш для ускорения повторного использования.

Если страницы долгое время остаются невостребованными - они перемещаются обратно на Memory Server. По-сути, эта технология представляет собой оптимизацию механизма паджинации. В то же время, здесь пока существуют следующие проблемы:

• Сбои, связанные с доступом к Cluster Memory
• Безопасность и сохранность данных
• Управление ресурсами в распределенной среде
• Увеличение потребления межсерверного канала
• Управление жизненным циклом страниц
• Производительность механизма в целом

В рамках демо на VMworld 2019 была показана технология Cluster Memory в действии для виртуальной машины, использующей 3 ГБ такой памяти.

Конечно же, самая интересная проблема - это производительность ВМ в таких условиях. VMware сделала некоторые тесты, где были использованы различные соотношения локальной и удаленной памяти. На получившемся графике видна производительность в числе выполненных операций в минуту:

Обратите внимание, и это здесь четко видно, что Cluster Memory всегда работает быстрее, чем локальный SSD-Swap. Второй важный момент тут, что даже при 70% использовании удаленной памяти виртуальная машина, с точки зрения производительности, чувствует себя вполне хорошо.

Понятно, что технология VMware Cluster Memory еще дело будущего, но пока вы можете посмотреть интересную запись упомянутой сессии на VMworld.

Давно компания VMware не обновляла на VMware Labs решение VMware vSphere HTML5 Web Client, которое по-сути и есть vSphere Client, включаемый в дистрибутивы VMware vSphere как основное и (теперь уже) единственное средство для управления виртуальной инфраструктурой.

Напомним, что именно как Fling клиент vSphere Client обновлялся довольно давно (о версии 4.1 мы писали вот тут, потом была еще версия 4.2). И вот на днях был выпущен vSphere HTML5 Web Client версии 4.3.

Давайте посмотрим, что нового в клиенте vSphere Client:

• Возможность кастомизировать цвет в заголовке окна клиента, чтобы отличать серверы vCenter. Для задания конкретного цвета конкретному vCenter идите в Administration -> System Configuration и выберите сервер, для которого нужно изменить цвет.
• Пофикшены проблемы с заливкой OVF-шаблона в библиотеку Content Library.
• Были убраны функции vSphere Perspective Management, которые появились ранее в версии 4.2. Они позволяли администратору контролировать области интерфейса, которые могли видеть другие пользователи VMware vSphere. Демо этой технологии можно посмотреть тут. Но, похоже, либо эта функциональность не зашла, либо ее отозвали на доработку и пока исключили из состава клиента.

Также в версии vSphere Client 4.2 были добавлены следующие полезные возможности:

• Режим Code Capture может захватывать и записывать операции с объектами Content Libraries.
• Code Capture может генерировать сценарии на других языках, в частности Python и vRO (vRealize Orchestrator) Javascript.

Скачать vSphere HTML5 Web Client 4.3 можно по этой ссылке.

В рамках серии анонсов, представленных на прошедшей конференции VMworld 2019, компания VMware представила интересное средство, которое может оказаться полезным администраторам виртуальной инфраструктуры - vSphere Assessment Tool (vSAT).

Главное назначение этой утилиты - помочь ИТ-специалистам перед миграцией инфраструктуры VMware vSphere на новую версию: заранее понять потенциальные проблемы с виртуальными машинами после апгрейда и проанализировать общую готовность инфраструктуры к обновлению. Также можно выявить возможные трудности в плане поддержки аппаратного обеспечения, что очень важно, когда у вас либо очень старое, либо очень новое оборудование.

Утилита vSAT реализована двумя компонентами:

• Десктопный клиент, который связывается с сервером vCenter и организует передачу данных.
• Онлайн-портал vSphere Assessment Portal, обрабатывающий ваши данный и визуализующий результаты.

Для начала работы просто нажимаете Get Started на первой странице портала:

Десктопный клиент поддерживает ОС Windows, OS X и Linux. В клиенте вы просто добавляете сервер vCenter, который нужно проанализировать. Для этого либо потребуется использовать административный аккаунт, либо создать пользователя с кастомной ролью с привилегиями "Host Settings".

После того, как в вашей инфраструктуре завершен сбор данных, есть 2 способа отправить их в облако:

• Онлайн-отправка на vSphere Assessment portal с использованием vSAT passcode (чтобы его получить, можно использовать опцию клиента "Forgot Your vSAT passcode?").

Также Passcode можно получить из меню аккаунта на vSAT Portal:

• Офлайн-отправка путем скачивания данных в файл и их последующая загрузка на портал в ручном режиме:

Результатом анализа будет дэшборд, на котором представлена сводная информация по имеющимся проблемам для выбранного пути апгрейда. В левой панели можно выбрать нужный хост ESXi (по аналогии с vSphere Client).

В представлении Summary вы найдете список всех версий vSphere, на которые вы можете выполнить миграцию, а также узнать, какие хосты ESXi рискуют оказаться в неподдерживаемой конфигурации. При клике на хост ESXi возникает панель host details, где можно увидеть текущую версию vSphere, модель сервера, сетевые адаптеры и контроллеры хранилищ. Для каждого компонента верифицируется поддержка соответствующей версией vSphere.

В общем, очень полезная штука для админа перед обновлением vSphere на новую версию. Особенно полезно будет запустить ее в большой инфраструктуре, где присутствует различное оборудование и, возможно, разные версии хостов ESXi.

Пользуйтесь!